The present invention relates generally to process control systems and, more particularly, to the automatic detection of problems existing within function blocks, devices and loops of a process control system.
Process control systems, like those used in chemical, petroleum or other processes, typically include a centralized process controller communicatively coupled to at least one host or operator workstation and to one or more field devices via analog, digital or combined analog/digital buses. The field devices, which may be, for example valves, valve positioners, switches and transmitters (e.g., temperature, pressure and flow rate sensors), perform functions within the process such as opening or closing valves and measuring process parameters. The process controller receives signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices, uses this information to implement a control routine and then generates control signals which are sent over the buses to the field devices to control the operation of the process. Information from the field devices and the controller is typically made available to one or more applications executed by the operator workstation to enable an operator to perform any desired function with respect to the process, such as viewing the current state of the process, modifying the operation of the process, etc.
In the past, conventional field devices were used to send and receive analog (e.g., 4 to 20 milliamp) signals to and from the process controller via an analog bus or analog lines. These 4 to 20 ma signals were limited in nature in that they were indicative of measurements made by the device or of control signals generated by the controller required to control the operation of the device. However, in the past decade or so, smart field devices including a microprocessor and a memory have become prevalent in the process control industry. In addition to performing a primary function within the process, smart field devices store data pertaining to the device, communicate with the controller and/or other devices in a digital or combined digital and analog format, and perform secondary tasks such as self-calibration, identification, diagnostics, etc. A number of standard and open smart device communication protocols such as the HART(copyright), PROFIBUS(copyright), WORLDFIP(copyright), Device-Net(copyright), and CAN protocols, have been developed to enable smart field devices made by different manufacturers to be used together within the same process control network.
Moreover, there has been a move within the process control industry to decentralize process control functions. For example, the all-digital, two-wire bus protocol promulgated by the Fieldbus Foundation, known as the FOUNDATION(trademark) Fieldbus (hereinafter xe2x80x9cFieldbusxe2x80x9d) protocol uses function blocks located in different field devices to perform control operations previously performed within a centralized controller. In particular, each Fieldbus field device is capable of including and executing one or more function blocks, each of which receives inputs from and/or provides outputs to other function blocks (either within the same device or within different devices), and performs some process control operation, such as measuring or detecting a process parameter, controlling a device or performing a control operation, such as implementing a proportional-derivative-integral (PID) control routine. The different function blocks within a process control system are configured to communicate with each other (e.g., over a bus) to form one or more process control loops, the individual operations of which are spread throughout the process and are, thus, decentralized.
With the advent of smart field devices, it is more important than ever to be able to quickly diagnose and correct problems that occur within a process control system, as the failure to detect and correct poorly performing loops and devices leads to sub-optimal performance of the process, which can be costly in terms of both the quality and the quantity of the product being produced. Many smart devices currently include self-diagnostic and/or calibration routines that can be used to detect and correct problems within the device. For example, the FieldVue and ValveLink devices made by Fisher Controls International Inc. have diagnostic capabilities that can be used to detect certain problems within those devices and also have calibration procedures that can be used to correct problems, once detected. However, an operator must suspect that a problem exists with the device before he or she is likely to use such diagnostic or calibration features of the devices. There are also other process control tools, such as auto-tuners that can be used to correct poorly tuned loops within a process control network. Again, however, it is necessary to identify a poorly operating loop before such auto-tuners can be used effectively. Similarly, there are other, more complex, diagnostic tools, such as expert systems, correlation analysis tools, spectrum analysis tools, neural networks, etc. which use process data collected for a device or a loop to detect problems therein. Unfortunately, these tools are data intensive and it is practically impossible to collect and store all of the high speed data required to implement such tools on each process control device or loop of a process control system in any kind of systematic manner. Thus, again, it is necessary to identify a problem loop or a device before being able to effectively use these tools.
Still further, each device or function block within a smart process control network typically detects major errors that occur therein and sends a signal, such as an alarm or an event, to notify a controller or a host device that an error or some other problem has occurred. However, the occurrence of these alarms or events does not necessarily indicate a long-term problem with the device or loop that must be corrected, because these alarms or events may be generated in response to (or be caused by) other factors that were not a result of a poorly performing device or loop. Thus, the fact that a device or a function block within a loop generates an alarm or event does not necessarily mean that the device or loop has a problem that needs to be corrected. On the other hand, many devices can have problems without the problem rising to the level of severity to be detected as an alarm or an event.
To initially detect problems within the process control system, a process control operator or technician generally has to perform a manual review of data generated within a process control system (such as alarms and events, as well as other device and loop data) to identify which devices or loops are operating sub-optimally or are improperly tuned. This manual review requires the operator to have a great deal of expertise in detecting problems based on raw data and, even with such expertise, the task can be time-consuming at best and overwhelming at worst. For example, an instrumentation department of even a medium-sized operating plant may include between 3,000 and 6,000 field devices such as valves and transmitters. In such an environment, the instrument technician or control engineer responsible for a process area simply does not have the time to review the operation of all the field device instrumentation and control loops to detect which loops or devices may not be operating properly or may have some problem therein. In fact, because of limited manpower, the only devices usually scheduled for maintenance are those that have degraded to the point that they dramatically impact the quantity or quality of the product being produced. As a result, other devices or loops which need to be retuned or which otherwise have a problem therein that could be corrected using the tools at hand are not corrected, leading to the overall degraded performance of the process control system.
A diagnostic tool for use in a process control system automatically collects and stores data pertaining to the different function blocks of devices and loops within the system, processes that data to determine which function blocks, devices, or loops have problems that may result in the reduced performance of the process control system, and then may suggest the use of other, more specific diagnostic tools to further analyze and correct the problem. The diagnostic tool may detect problems or identify poorly performing devices or loops using a variability indication, a mode indication, a status indication or a limit indication associated with each of the function blocks or devices within a process control system. The variability indication is preferably determined or partially determined by each function block within the process control system to provide a statistical measurement of the deviation of a parameter associated with the device or function block from a set point or other value associated with the device or function block. The mode indication identifies the mode in which a function block or device is operating, e.g., a normal mode or a non-normal mode, to indicate if the device or function block is operating in its designed mode. The status indication identifies the quality of a signal associated with the function block or device at any given time. The limit indication may identify if a function block signal is limited in nature.
The diagnostic tool may determine which function blocks, devices or loops have problems associated therewith based on the instantaneous values or on a compilation of the historical values of one or more of the variability indication, the mode indication, the status indication, the limit indication or other data associated with each function block or device. Thereafter, the diagnostic tool may report detected problems to an operator via a display screen and/or may generate written reports (such as printed reports) or electronic reports sent, for example, over the internet (e.g., through E-mail) to concerned persons.
Furthermore, upon detecting problems within one or more process control devices or loops, the diagnostic tool may suggest the proper tool(s) to be used to further pinpoint the problem and/or to correct the detected problem. If requested to do so, the diagnostic tool executes these further tools on a host workstation to enable an operator to perform further diagnostic functions. In cases where the diagnostic tool requires the use of further data intensive tools to diagnose or pinpoint a specific problem (such as an expert system or a correlation analysis tool), the diagnostic tool may automatically configure the host system to collect the data needed to run that further tool.
In this manner, the diagnostic tool identifies the function blocks, devices, loops, etc. which need attention without requiring an operator to review massive amounts of data pertaining to numerous devices and loops within a process control system. This saves time on the part of the operator and does not require the operator to have a great deal of expertise in detecting problem loops and devices. Also, upon detecting a problem, the diagnostic tool may recommend the use of further tools to pinpoint and/or correct the problem, which enables the operator to correct problems without having to guess as to which tool is the most appropriate in any given situation. Besides saving time, this function reduces the burden on the operator and helps to assure that the proper diagnostic tools are used in each circumstance.